NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/4616

Internet Message Format | 1996-08-06 | 3.4 KB

Path: newspost1.alt.net!usenet
From: [e-mail] (Walt Howard)
Newsgroups: comp.lang.c++
Subject: Re: How to handle error in constructor
Date: Wed, 31 Jan 1996 09:14:27 GMT
Organization: AltNet - Affordable Usenet Access - http://www.alt.net
Message-ID: <4enbts$[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
X-Newsreader: Forte Agent .99c/32.126

On Tue, 30 Jan 1996 00:54:21 GMT, [e-mail] (Andrew
Phillips) wrote:

>I'm converting and enhancing a simple program in C to C++.  Without going
>into too much detail I have a class that represents a file on disk.  The
>contructor opens the file, but what should it do if the file cannot be
>opened?  The C program just calls fopen() tests the return value and
>if there's an error it prints a message and exits.
>
>In C++ I thought to set a flag in the constructor and have a member function
>that tests the flag to see if the file was opened correctly.  This seems
>rather inelegant -- I guess exceptions would be the elegant way but seem
>like overkill for such a simple program.  I've looked in several C++ books but
>error handling is given scant coverage except for exception handling.
>
>Any suggestions would be greatly appreciated.
>

There are several approaches. The one you came up with is similar to
what the C++ stream library does. However, that was written before
exceptions were available.

Exceptions is the only way to go on this. And you shouldn't consider
them overkill, they really aren't. All you have to say is, for
example:

try
{
    if ( action() == fail )
        throw( "dang file didn't open" );
            //Here I "throw" a char* pointer
}
catch( char* errorMessage ) // and here I catch it and deal with it
{
    printf( "%s", errorMessage );
    exit( -1 ); // or whatever
}

Try it a few times and you'll see how simple it is. The books make it
seem complicated but it isn't. The rewards are well worth it.

Exceptions will reliably trap and clean up a bad construction and I
recommend using them as such, however there are some other issues
involved.

From my experience, I would say that any class whose constructor has
ANY chance to fail, should not do the failure-possible action during
the constructor. Have a function called init(void) (always void
argument) that does the actual activation of the object.

Have the constructor do EVERYTHING necessary to prime/lock and load
the object, but the init( ) function actually pulls the trigger. The
init() function should just have (void) as an argument because all its
going to do is pull the trigger right?

For a file object, the construction might set the name and file access
mode but the init() function would actually OPEN the file.

This has many benefits. For example, if you're object's constructor
can fail, GLOBAL objects (those constructed at startup time) can fail
and you can't trap that with an try/catch exception handler. Way
bummer.

There are other benefits but I think you'll see this way is good after

some experience.

Plus, you can always overload another construction to automatically
call the init() function also to get the functionality of the FULL
construction if you want.

--
>Andrew Phillips (News/Sys Admin)  [e-mail]  [phone]
>--------------------------------
>Just a SPOKE, not a SPOKESPERSON

//////////////////////////////////////////////////////////
C++ programmers like to see the forest. C programmers like
to see the trees.

Walt Howard